Performance evaluation of the TFD-capable dynamic QoS assurance of HD video streaming in well-dimensioned network

The Traffic Flow Description (TFD) option of the IP protocol is an experimental option, designed by the Authors and described by the IETF’s Internet Draft. This option was intended for signalling for QoS purposes. Knowledge about forthcoming traffic (such as the amount of data that will be transferred in a given period of time) is conveyed in the fields of the option between end-systems. TFD-capable routers on a path (or a multicast tree) between the sender and receiver(s) are able to read this information, process it and use it for bandwidth allocation. If the time horizons are short enough, bandwidth allocation will be performed dynamically. In the paper a performance evaluation of an HD video transmission QoS assured with the use of the TFD option is presented. The analysis was made for a variable number of video streams and a variable number of TCP flows that compete with the videos for the bandwidth of the shared link. Results show that the dynamic bandwidth allocation using the TFD option better assures the QoS of HD video than the classic solution, based on the RSVP protocol

Estimation of Link Occupancy During TCP Transmissions in Internet of Things

Jednym z problemów występujących w dużych systemach Internetu Rzeczy, złożonych z tysięcy urządzeń IoT, są przeciążenia sieci w pobliżu urządzeń pełniących rolę hubów komunikacyjnych (brokerów danych, chmur obliczeniowych). Przeciążenia te nie są w wystarczającym stopniu rozładowywane przez protokół TCP, który (ze względu na specyfikę ruchu telekomunikacyjnego w systemach IoT) nie jest w stanie prawidłowo oszacować, dostępnych dla danej transmisji, zasobów sieciowych. W artykule przedstawiono prototypowe urządzenie IoT, zbudowane na mikrokontrolerze Raspberry PI pracującym pod kontrolą systemu operacyjnego Linux, które szacuje wielkość, dostępnej dla protokołu TCP, przepustowości ścieżki komunikacyjnej. Urządzenie korzysta ze znanej metody par pakietów. Aby poprawić dokładność szacunków, użyto wariantu metody, który ocenia wielkość dostępnej przepustowości na podstawie ciągów par. Badania przeprowadzone w dedykowanej sieci lokalnej pozwoliły zarówno ocenić pracę urządzenia, jak i dokonać analizy dokładności szacunków przeprowadzanych w obecności ruchu charakterystycznego dla systemów Internetu Rzeczy. Oceniono również narzut ruchu wnoszonego do sieci Internetu Rzeczy przez pomiary metodą par testowych TCP. Ze względu na ograniczoną moc obliczeniową mikrokontrolera Raspberry PI, urządzenie korzysta z prostych, szybkich wariantów obliczeniowych metody par pakietów PTR (bez odstępu czasowego między parami pakietów) oraz zmodyfikowany IGI (ze zmiennym odstępem czasowym między parami pakietów). Urządzenie umożliwia szybką ocenę stanu sieci w trakcie trwania transmisji IoT. Znajomość stanu sieci, w tym przepustowości dostępnej dla transmisji TCP, pozwoli na efektywniejsze działanie systemu wykorzystującego dużą liczbę urządzeń Internetu Rzeczy.One of the serious problems with large-scale Internet of Things systems, composed of thousands of IoT devices, are network congestions that occur near communication hubs (data brokers, computing clouds). These congestions cannot be enoughly discharged by the TCP protocol, which (due to specific teletraffic, generated by IoT devices) is not able to correctly estimate bandwidth available for a given transmission. In this article, a prototype IoT device that estimates amount of bandwidth of transmission path, available for TCP transmissions, is presented. The device is built with the use of the Raspberry PI microcontroller, working under the control of the Linux operating system, and uses packet pairs method for bandwidth estimation. To improve estimation accuracy, Probing Packet Trains (PPT) variant of packet pairs method was used. Results of experiments carried out in local area network are presented in figures and includes both analysis of estimation accuracy, and analysis of amount of control traffic that will be injected to an IoT network during a single measurement with the use of several probing packet trains. Due to limited computing power of the Raspberry PI, the device uses two, simple for computing, versions of the PPT: Packet Transmission Rate and Initial Gap Increasing. The device enables fast assessment of networks conditions. Knowledge of bit rate available for current TCP transmissions allows for more efficient performance of IoT systems that use large amount of devices

O gwarantowanej jakości usługi Internetu Rzeczy zintegrowanej z systemem wideokonferencyjnym

In this paper, an analysis of Internet of Things (IoT) system, integrated with a videoconferencing system built according to the WebRTC architecture, is presented. Analysis covers Quality of Service (QoS) levels of the MQTT protocol, number of active IoT devices and location of a corresponding WebRTC terminal.Artykuł przedstawia analizę systemu Internetu Rzeczy zintegrowanego z systemem wideokonferencyjnym zbudowanym zgodnie z architekturą WebRTC. Dane aplikacji Internetu Rzeczy przesyłane są pomiędzy terminalami kanałem danych WebRTC, równocześnie z danymi wideokonferencji. Analiza uwzględnia poziomy QoS protokołu MQTT, liczbę aktywnych urządzeń Internetu Rzeczy oraz lokalizację terminali (pobliską i odległą)

Model warstwowy ustanawiania sesji WebRTC

This paper presents a layered model of the WebRTC session establishment, extracted from documentation and software implementation. The model's presentation is illustrated by examples of multimedia transmissions carried out directly between Web browsers and between a Web browser and a VoIP terminal.Artykuł przedstawia warstwowy model opisujący ustanawianie sesji WebRTC, uzyskany na podstawie analizy dokumentacji protokołów biorących udział w ustanawianiu sesji oraz kodów źródłowych przeglądarek internetowych. Prezentację modelu zilustrowano przykładami transmisji multimedialnej pomiędzy przeglądarkami WWW oraz pomiędzy przeglądarką a terminalem VoIP

ECN-capable TCP-friendly Layered Multicast Multimedia Delivery

ECN-capable TCP-friendly layered multicast multimedia delivery combines explicit congestion notification (ECN) with the TCP-friendly layered multicast scheme. TCP-Friendliness denotes that receiver– driven architecture behaves under congestion like the TCP protocol. Unlike well-known TCP-friendly protocols (TFRC, TFMCC, WEBRC), which use TCP throughput the equation, our system assures TCPfriendliness by emulation. The Receiver emulates TCP congestion control mechanism working with ECN congestion notification. Decisions about changing group membership and, as a result, about changing effective transmission rate, are taken based on TCP emulation. In the paper, a simulation model of ECN-capable multicast multimedia delivery in ns-2 environment is discussed

Co-operation of signalling client with a simple signalling server

W artykule przedstawiono budowę klienta sygnalizacji współpracującego z prostym serwerem sygnalizacyjnym. Klient taki może być prostym klientem, wymagającym jedynie podstawowej sygnalizacji, lub bardziej złożonym. Jako przykład systemu o większym stopniu złożoności pokazano aplikację zgodną z architekturą WebRTC. W artykule przedstawiona została przykładowa komunikacja pomiędzy klientem i serwerem zebrana podczas sesji WebRTC. Artykuł zawiera również przykłady dwóch rozwiązań aplikacji czatu internetowego, które wykorzystują ten sam interfejs użytkownika oraz ten sam system sygnalizacji (drugie rozwiązanie rozszerza pierwsze o obsługę komunikatów sygnalizacyjnych techniki WebRTC), różnią się natomiast sposobem transmisji danych użytkownika (wiadomości tekstowych czatu). W pierwszym rozwiązaniu dane użytkownika przenoszone są kanałem sygnalizacyjnym (via serwer sygnalizacyjny) z wykorzystaniem interfejsu WebSocket. W drugim rozwiązaniu dane użytkownika przenoszone są bezpośrednio pomiędzy przeglądarkami (kanałem WebRTC przeznaczonym do transmisji danych niemedialnych) z wykorzystaniem interfejsu RTCDataChannel techniki WebRTC.A simple signalling server, written in JavaScript and running in node.js run-time environment, was presented in the previous paper of the Authors [3]. In this paper, principles of building of WebRTC signalling client are presented, as well as exemplary communication between the client and the server, captured with the use of WireShark software tool during experimental WebRTC sessions. The paper includes also an example of application of Internet chat, that uses the simple signalling server [3]. The chat was builreneusz in two versions, which uses the same user interface and their signalling systems were build according to the same methodology, but differs in method of transmission of chat messages. The first version transmits user data (text messages of the chat) via signalling server, with the use of signalling channel. This version uses WebSocket interface for transmission of chat messages. In the case of the second version, user data are transmitted directly between web browsers, using WebRTC's channel dedicated for transmission of nonmedia data. This version transmits chat messages with the use of WebRTC's RTCDataChannel interface

Analiza statystyczna ruchu wideo o rozdzielczości 4K

Nowadays we observe a rapid growth of 4K video, what lead to increase of number of 4K transmissions. The article will present method of acquisition of time series of sizes of video frames encoded to 4k resolution standard, and preliminary results of statistical analysis of these time series (measures of location and measures of dispersion).Ruch wideo przesyłany jest z coraz większymi rozdzielczościami, przy zastosowaniu coraz bardziej złożonych algorytmów kodowania i kompresji. Obecnie obserwujemy gwałtowny wzrost liczby transmisji wideo 4K. W artykule zostaną zaprezentowane sposób pozyskiwania szeregów czasowych rozmiarów ramek wideo o wysokiej rozdzielczości obrazu (standard 4K) oraz ich wstępna analiza statystyczna (podstawowe miary położenia i rozproszenia)

O gwarancjach jakościowych dla ruchu elastycznego

In this paper, the problem of Quality of Service (QoS) guarantees for elastic traffic is described. The paper describes two existing solutions of QoS for elastic traffic – the MQTT protocol and the TCP protocol. A concept of usage of signaling based on the Traffic Flow Description option also was shown.Niniejszy artykuł omawia problematykę gwarancji jakościowych dla ruchu elastycznego. W artykule posłużono się przykładami dwóch istniejących rozwiązań: protokołu sygnalizacyjnego MQTT przeznaczonego do współpracy z Internetem Rzeczy oraz protokołu transportowego TCP ogólnego przeznaczenia. Zaproponowano również zastosowanie sygnalizacji za pomocą opcji TFD protokołu IP, zgłoszonej jako Internet Draft i przeznaczonej do opisu ruchu

An Analysis of Elastic and Inelastic Traffic in Shared Link

Abstract — Nowadays, we observe rapid growth of multimedia transmissions in the Internet. Multimedia are typically carried out using the RTP protocol, while the rest of Internet traffic is transmitted via the TCP protocol. In the paper the problem of coexistence of elastic and inelastic traffic is presented. In contrast to other papers, which analyze this issue as the problem of TCP-unfriendliness of the RTP protocol, we focus on this coexistence from multimedia point of view